Palette bit depth rounds down instead of up

bitdepthFromColourCount maps the colours option to a PNG/GIF palette bit depth of 1, 2, 4 or 8, but it rounds the required bit count down to the nearest power of two, so a value needing 5 to 8 bits is capped at 4 and one needing 3 bits at 2. png({ colours: 128 }) and gif({ colours: 100 }) therefore emit a 16-entry palette, and colours: 8 a 4-entry one, quietly discarding colours the caller asked to keep (visible via metadata bitsPerSample). Rounding up instead keeps the stored depth one of 1/2/4/8 while making it large enough to hold the requested count.

The reduced-colours GIF size test happened to depend on the old behaviour, as colours: 128 only shrank the file because it collapsed to 16 entries, so it now uses colours: 16 which still exercises a genuinely smaller palette. Added a PNG regression test asserting the written bit depth can represent the requested number of colours.